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REMARKS 

The Office Action mailed January 21, 2009 has been received and reviewed. 
Each of claims 1-55 stands rejected. No claims have been amended herein. Reconsideration of 
the above-identified application in view of the following remarks is respectfully requested. 

Rejections based on 35 U.S.C. § 103 

Claims 1-3, 5, 11-19, 21. 27-33, 37-41, 45-49-53 and 55 were rejected under 35 
U.S.C. 103(a) as ostensibly being unpatentable over Baldwin (U.S. Publication No. 
2003/10149749, hereinafter the "Baldwin reference") in view of Araujo et al. (U.S. Patent No. 
6,118,785, hereinafter the "Araujo reference"). 

Claims 4, 7, 20 and 23 were rejected under 35 U.S.C. 103(a) as ostensibly being 
unpatentable over Baldwin and Araujo and further in view of Lin (U.S. Patent No. 7,117,530, 
hereinafter the "Lin reference"). 

Claims 6, 22, 34 and 42 were rejected under 35 U.S.C. 103(a) as ostensibly being 
unpatentable over Baldwin and Araujo and further in view of Arrow (U.S. Patent No. 6,226,751, 
hereinafter the "Arrow reference"). 

Claims 8-10, 24-26, 35, 36, 43 and 44 were rejected under 35 U.S.C. 103(a) as 
ostensibly being unpatentable over Baldwin and Araujo and further in view of Baldwin (U.S. 
Publication No. 2003/0078996, hereinafter the "Baldwin '996 reference"). 
Previous Arguments 

Applicants respectfully submit that the Office has failed to take note of 
Applicants' arguments presented in our Response of 11/01/2007. Moreover, it has failed to 
respond to the substance of our arguments. See MPEP § 707.07(f). Accordingly, Applicant 
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incorporates all of its comments from our Repsonse of 11/01/2007 herein, and offers further 
comments. 

The Office continues to equate the "ensoBox" taught by Baldwin with the 
"enhancement cluster" as claimed by Applicants. As mentioned, Baldwin 746 describes an all- 
inclusive appliance (called an "ensoBox") for Internet Service Providers (ISPs). Baldwin at f 
[0005]. The functional goal of the ensoBox invention described in Baldwin is to provide 
services and Internet access to subscribers of an ISP franchise and to provide back-office 
management software required to run the ISP. Baldwin at 1 [00310]. Accordingly the ensoBox 
appliance described in Baldwin is not like the Applicant's claimed "enhancement cluster". The 
ensoBox appliance includes the input interface (Remote Access Servers). See Baldwin FIGs. 2- 
4. Specifically, the input interface, which receives modem-calls, is part of the Access Node 
component of the ensoBox. Baldwin ffl [0153] to [0155]. 

Additionally, "[t]he functionality of the ensoBox is divided into three modules, or 
nodes, called the Core Node, Access Node, and Services Node." Baldwin at ^ [0281]. Each 
Access Node is associated with a specific Core Node and Sei-vices Node. As the examiner 
points out, the purpose of the Core Node is to serve as the middle-man between the Internet and 
the PSTN. Baldwin at i [0137]. "[The Core Node] connects dkecdy to the Internet" and "[i]t 
also connects directly to the Access Node." Baldwin at ^ [0137]. The connection between the 
Access Node and the Core Node is formed using 4 dedicated circuits; two of which are reserved 
for a subscribers' VLAN and the other two are reserved for Management VLAN. Baldwin at f 
[0320]. Baldwin further notes that two circuits for each VLAN are used to provide redundancy 
"in the event of failure to one of the circuits." Baldwin at 1 [0137]. 
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The Core Node is connected to the Services Node in a similar manner. Baldwin at 
^ [0327]. Thus, according to Baldwin, a user who connects to the input interface must connect, 
via a dedicated connection within the ensoBox, to a specific core node, offering internet access, 
and services node, offering services. There is no "virtual point-to-point connection" between an 
input interface and an enhancement cluster "based on the destination address or other identifier" 
as recited in applicant's currently amended claims, because the all calls received by the input 
interface within the Access Node are connected via dedicated connections to a Core Node and 
Services Note associated with that Access Node.^ 



35 U.S.C. § 103 Rejections 

With regard to claim 1, the Office states the following: 

...at least one virtual point-to-point connection for communicating 
the encapsulated tunnel-protocol-encapsulated data packets over at 
least one communications path traversing the at least one 
asymmetric-routing data network and operable to convey data- 
types that utilize a point-to-point connection, wherein the at least 
one communications path couples the input interface to the at least 
one enhancement cluster based on the destination address, 
(Baldwin discloses having a PPP session interpreted as a 'point-to- 
point connection' within a network that comprise of a PSTN and 
the Internet interpreted as a 'asymmetric-routing data network', see 
fig. 2-4 and page 8 paragraph 223). It is known in the art the 
packets are encapsulated in a PPP connection. Baldwin further 
discloses having a plurality of communication paths coupled to 
remote access servers to the ensobox (fig. 2-4). 

Ojfice Action of 01/21/2009, pp. 4,5. But Applicants respectfully submit that 
Baldwin does not teach or suggest "virtual point-to-point connections" as claimed by Applicants. 

Applicants' virtual point-to-point connections are encapsulated in a higher-level tunneling 
protocol: "[t]he data packets may be encapsulated in a higher-level tunneling protocol, so that 



^ Applicants' After Final Response to Final Office Action of 1 1/01/2007, pp. 15,16 
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the transmitted data may still assume that PPP-type transport is being used. In this manner, dial- 
site owners or operators may allow end users to make use of the asymmetric data network to 
establish virtual point-to-point connections with providers." Applicants, ^[0007]. In contrast, 
Baldwin teaches actual PPP connections between a user and the ensoBox via a PSTN. What 
Baldwin teaches is very different from what is claimed by Applicants, as explained below. 

A tunneling protocol may be used to control the routing of packets within a 
network. Typical IP communications send data packets into a network on a connectionless basis, 
so that data packets traverse any available route to their destination. As a generic example of 
this, suppose that data packets are addressed to a destination A, but it is desired that the data 
packets travel through a specific location B in the network en route to destination A, perhaps to 
perform some type of processing on the data packets before delivering them to destination A. If 
they are simply sent over the network, it is unlikely that the data packets would traverse a path 
through location B by chance. However, they can be encapsulated and routed through a tunnel to 
location B, where they are decapsulated, processed, then allowed to continue on to destination A. 
Their original destination IP address (destination A) is retained within the encapsulation such 
that once they are decapsulated, the data packets retain the original address of destination A and 
can be sent to their original destination in the network. Similarly, in embodiments of the present 
invention, data received from a PPP modem connection is "encapsulated in a tunneling-protocol" 
and sent "using the tunneling protocol for delivery via one or more virtual point-to-point 
connections based on a destination address associated with the tunneling-protocol-encapsulated 
data packets" as claimed by Applicants. (Note that the "'virtual point-to-point connections" are 
not the actual point-to-point connections taught by Baldwin. Baldwin teaches actual point-to- 
point connections between a user and the ensoBox, over a PSTN. Applicants claim "virtual 
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point-to-point connections" over an "asymmetric-routing network.") In embodiments of the 
present invention, data received from modem connections is desired to be processed by an 
"enhancement cluster." Exemplary processing is compression of the data in order to provide a 
more responsive session for a user. But the user does not connect directly to the "enhancement 
cluster" via modem or any other means. The "enhancement cluster" communicates over the 
asymmetric network, not over a circuit- switched network (PSTN). "[D]ata packets... are 
encapsulated in a tunneling-protocol," as claimed by Applicants, and are tunneled to the 
enhancement cluster. 

Applicants respectfully submit that Baldwin does not teach or suggest "data 
packets that are encapsulated in a tunneling-protocol" as claimed by Applicants. Rather, 
Baldwin teaches that the Core Node Router simply routes the received packets to their 
destination: "[s]ubscriber data requests are switched from the Access Node Switch to the Core 
Node Router where they are then routed to the appropriate destination. If the destination is not 
within the ensoBoxTM domain, but instead resides within the Internet, the Core Node Router 
uses a default route to the Internet for processing." Baldwin, 1[0323]. Nowhere does Baldwin 
teach or suggest that the packets are tunneled to an "enhancement cluster" or any other location. 

The Office concedes that "Baldwin does not explicitiy disclose operable to send 
using a tunneling protocol for delivery via one or more virtual point-to-point connections" and 
states that "Araujo et al. discloses having a point-to-point protocol with a signaling channel 
(title) [and] also having a enhanced PPP (point to point protocol) whereby transmitting data 
within a VC virtual circuit to ISP Remote Access Server (RAS), see column 9 line 12-20 and 
encapsulation for PP data packets sent between two L2TP (layer 2 tunnel protocol) endpoints, 
see column 9 lines 28-30 and fig. 1." Office Action of 01/21/2009, p. 5. 
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However, Applicants respectfully submit that the Office fails to address "based on 
a destination address associated with the tunneling-protocol-encapsulated data packets" as 
claimed by Applicants. Stated more fully. Applicants claim: "operable to send using the 
tunneling protocol for delivery via one or more virtual point-to-point connections based on a 
destination address associated with the tunneling-protocol-encapsulated data packets." In 
embodiments of the present invention, not all received modem data is directed to the 
enhancement cluster. The determination to direct data to the enhancement cluster is based on the 
destination address of the data. This is described in the Applicants' specification: "...according 
to the invention in one regard the user may dial in to the set of remote access servers 106, for 
instance a private Internet provider dial site, which may sense the call as being designated for 
enhanced service and direct the transport to PPP-compatible links. For example, the 
authentication servers 112 may detect an enhanced call through the use of a special domain 
name or extension. That domain name or extension may for example take the form 
'Enhanced.Sprint.com' or other. The set of authentication servers 112 may interpret that target 
domain as a request to access enhanced throughput, storage or other sei-vices. In embodiments, 
the dialer, browser or other client or other software being used by the user may attempt to 
establish a PPP session to directly connect to the desired Web site. However, according to the 
invention that modem call may be directed by the set of remote access servers 106 to tunnel 116 
and ultimately to the enhancement cluster 118, based on the destination address or other 
identifier." Applicants, ff [0020], [0021]. 

In contrast, Baldwin teaches that a modem connection is made to the ensoBox and 
the received modem data is routed to its destination by the Core node, whether that destination is 
within the ensoBox domain or on the Internet: "Subscriber data requests are switched from the 
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Access Node Switch to the Core Node Router where they are then routed to the appropriate 
destination. If the destination is not within the ensoBoxTM domain, but instead resides within 
the Internet, the Core Node Router uses a default route to the Internet for processing." Baldwin, 
% [0323]. Baldwin does not teach or suggest "operable to send using the tunneling protocol for 
delivery. . .based on a destination address associated with the tunneling-protocol-encapsulated 
data packets" as claimed by Applicants. It should be noted that the "destination address" 
claimed by Applicants is not the address of the enhancement cluster, as discussed above. 

Baldwin does not tunnel the data to an enhancement cluster based on the 
destination address. Baldwin simply routes the data to its destination. There is no enhancement 
cluster taught or suggested by Baldwin, nor does the ensoBox or the Core Node correspond to 
the enhancement cluster, as discussed above. 

With continued reference to the Office's concession that "Baldwin does not 
explicitly disclose operable to send using a tunneling protocol for delivery via one or more 
virtual point-to-point connections" and statement that "Araujo et al. discloses having a point-to- 
point protocol with a signaling channel (title) [and] also having a enhanced PPP (point to point 
protocol) whereby transmitting data within a VC virtual circuit to ISP Remote Access Server 
(RAS), see column 9 line 12-20 and encapsulation for PP data packets sent between two L2TP 
(layer 2 tunnel protocol) endpoints, see column 9 lines 28-30 and fig. 1" (see Office Action of 
01/21/2009, p. 5.), Applicants respectfully disagree that Araujo teaches or suggests "operable to 
send using the tunneling protocol for delivery via one or more virtual point-to-point connections" 
as claimed by Applicants. Araujo teaches tunneling for a specific reason to address a specific 
need. In Araujo, tunneling is used for the purpose of multiplexing multiple PPP connections 
over a single channel between users and a remote access server. "Local loops connect modems 
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at customers premises to a central office switch on the public switched telephone network. At the 
central office switch, the telephone connection is routed to its destination, either directly or 
through other equipment in the network. As data traffic increases, the companies that provide 
access to Internet Service Providers across their telephone networks (access providers) are 
diverting the data traffic off of the voice networks into networks more suited for data traffic or 
packet switched traffic. Thus, the central office switches are configured with a concentrator and 
multiplexer for data traffic which is split off of the voice traffic. The communication of the data 
traffic from the central office switch to a remote access server or other destination is processed 
by the concentrator/multiplexer to optimize use of the access provider's available bandwidth. For 
example, access providers are beginning to deploy equipment that diverts calls destined for 
Internet Service Providers off of the voice switching network, which terminates calls, extracts 
PPP packets and encapsulates the packets within logical connections in a tunnel. A tunnel is a 
conmiunication channel which operates according to a tunneling protocol, including the point-to- 
point tunneling protocol PPTP, the layer 2 forwarding protocol L2F, the layer 2 tunneling 
protocol L2TP and equivalent protocols. The logical connections within a tunnel are used as a 
means for multiplexing the data from several users into a single tunnel." Araujo, col. 2, 11. 10- 
36. Araujo further teaches: "In FIG. 8, PPP data from several ADSL endpoints is sent from the 
access multiplexer to the ISP RAS. This is why the extra L2TP encapsulation (packet 130) is 
needed-this encapsulation allows for multiplexing the data from the different PPP sessions, 
where each session will be identified by a unique Tunnel ID and Call ID." Araujo, col. 10, 11. 5- 
11. In Araujo, tunneling is used specifically to multiplex data from multiple modem sessions in 
order to reduce the required bandwidth between the central office switch and a remote access 
server in order to optimize use of the access provider's available bandwidth. The modem data is 
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tunneled to the remote access server. This is in contrast to what Applicants describe-after the 
modem data has been received at the input interface {e.g. remote access server) it is tunneled to 
an enhancement cluster: "an input interface that receives data associated with a modem-based 
data session... that is capable of facilitating a transfer... of data packets... in a tunneling 
protocol..." and "wherein the... communications path couples the input interface to 
the... enhancement cluster" as recited by Applicants in claim 1. Further, what is recited in claim 
1 is clearly described in the specification: "More specifically, the set of remote access servers 
106 may receive IP datagrams from the set of end users 102, such as requests to view Web sites, 
email access, and other data, and communicate that data to concentration routers 114 for routing 
to processing by an enhancement cluster 118. In embodiments, the set of remote access servers 
106 may establish a secure virtual connection or tunnel 1 16 connecting the set of remote access 
servers 106, the set of switches 108, the access concentration routers 114 and that enhancement 
cluster 118." Applicants, \ [0017]. 

Further, Applicants respectfully submit that with respect to Araujo, as with 
Baldwin, the Office fails to address ''based on a destination address associated with the 
tunneling-protocol-encapsulated data packets" as claimed by Applicants. Stated more fully, 
Applicants claim: "operable to send using the tunneling protocol for delivery via one or more 
virtual point-to-point connections based on a destination address associated with the tunneling- 
protocol-encapsulated data packets." As discussed in some detail above, Araujo teaches 
tunneling for the purpose of multiplexing data from multiple modem sessions in order to reduce 
the required bandwidth between the central office switch and a remote access server in order to 
optimize use of the access provider's available bandwidth. The modem data is not tunneled 
''based on a destination address associated with the tunneling-protocol-encapsulated data 
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packets" as claimed by Applicants. The modem data is multiplexed through the tunnel to the 
remote access server in order to conserve bandwidth. It is not based on the destinations of the 
data packets. It should be noted that the remote access server is not the destination of the data 
packets. Each data packet has its own destination address. Embodiments of the present 
invention tunnel some modem data from the remote access server to an enhancement cluster 
based on the destination address of the data packets. 

With regard to claim 17, Applicants respectfully submit that the combination of 
Baldwin and Araujo does not teach every element of the claim for at least the reasons given 
above in regard to claim 1, and for at least the additional reasons given below. 

The Office states "Baldwin further discloses that the ensobox ("enhancement 
cluster") provides dial-up access to the Internet (page 3 paragraph 113 line 1-2)... and that the 
core node within the ensobox ("enhancement cluster") is the "middle man" between the Internet 
and the Public Switched Telephone Network (PSTN, paragraph 137 line 1-7). Applicants 
respectfully submit that the ensoBox taught by Baldwin is not like the "enhancement cluster" 
claimed by Applicants, for at least the reasons given above. 

Further, Applicants respectfully submit that Baldwin does not teach or suggest 
"encapsulating at the at least one remote access server packets of the data to be sent in a 
tunneling protocol for delivery via one or more virtual point-to-point connections" as claimed by 
Applicants, nor has the Office presented any arguments to the contrary. The modem data 
received by the remote access server is encapsulated at the remote access server. This is 
described by Applicants in the specification: "More specifically, the set of remote access servers 
106 may receive IP datagrams from the set of end users 102, such as requests to view Web sites, 
email access, and other data, and communicate that data to concentration routers 114 for routing 
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to processing by an enhancement cluster 118. In embodiments, the set of remote access servers 
106 may establish a secure virtual connection or tunnel 116 connecting the set of remote access 
servers 106, the set of switches 108, the access concentration routers 114 and that enhancement 
cluster 118." Applicants, \ [0017]. The Office argues, with regard to claim 1, that the PPP 
connection between a user and the remote access server (over a PSTN) constitutes encapsulation. 
Even if that were correct, in Baldwin the data received from the modem session is not 
encapsulated ''at the... remote access server. ..to be sent in a tunneling protocol" as recited by 
Applicants in claim 17. 

Further, Applicants respectfully submit that neither does Araujo teach or suggest 
"encapsulating at the at least one remote access server packets of the data to be sent in a 
tunneling protocol for delivery via one or more virtual point-to-point connections" as claimed by 
Applicants, nor has the Office presented any arguments to the contrary. As discussed above with 
regard to claim 1, Araujo encapsulates data packets and multiplexes them in a tunnel between a 
central office switch (in the PSTN) and a remote access server. However, Araujo does not teach 
or disclose that the data received from the modem session by the remote access server is 
encapsulated "a? the. ..remote access server.. .to be sent in a tunneling protocol" as recited by 
Applicants in claim 17. 

With regard to claim 33, Applicants respectfully submit that the combination of 
Baldwin and Araujo does not teach every element of the claim for at least the reasons given 
above in regard to claim 1 . 

With regard to claim 41, Applicants respectfully submit that the combination of 
Baldwin and Araujo does not teach every element of the claim for at least the reasons given 
above in regard to claims 1 and 17. 
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With regard to claim 49, Applicants respectfully submit that the combination of 
Baldwin and Araujo does not teach every element of the cMm for at least the reasons given 
above in regard to claims 1 and 17. 

For at least the reasons given above, independent claims 1, 17, 33, 41 and 49 are 
believed to be in condition for allowance. At least because claims 2-16, 18-32, 34-40, 42-48, 
and 50-55 depend directly or indirectly from base claims that are in condition for £illow£ince, they 
are believed to be in condition for allowance. Applicants respectfully request withdrawal of the 
35 U.S.C. § 103(a) rejections of claims 1-55. 
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CONCLUSION 

For at least the reasons stated above, claims 1-55 are now in condition for 
allowance. Applicants respectfully request withdrawal of the pending rejections and allowance 
of the claims. If any issues remain that would prevent issuance of this application, the Examiner 
is urged to contact the undersigned - 816-559-2173 or jcamacho @ shb.com (such communication 
via email is herein expressly granted) - to resolve the same. Other than the $130.00 extension 
fee discussed above, it is believed that no fee is due. However, the Commissioner is hereby 
authorized to charge any amount required to Deposit Account No. 21-0765. 

Respectfully submitted, 

/ Jesse J. Camacho / 

Jesse J. Camacho 
Reg. No. 51,258 

JJCZ/MMSZ/tq 

SHOOK, HARDY & BACON L.L.P. 

2555 Grand Blvd. 

Kansas City, MO 64108-2613 

816-559-2173 
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